In recent years, service oriented architectures have gained wide-spread acceptance. Service oriented architectures are data processing architectures based on interacting components. These components may be physical components (e.g., computers) and/or logical components (e.g., software modules running within a multitasking environment). Communication between the components may be provided by any communication mechanism, which may include a global network (e.g., the Internet), or an enterprise-wide network (e.g., an Intranet), or a local network, or a data communication mechanism within a single computer.
The components of a service oriented architecture interact through services. A service is usually considered as a function that receives requests and returns responses via a well-defined interface. In many systems, the services (or some of the services) process each request without having regard to other (earlier or concurrent) processing operations of the same or other services. This property is often called “statelessness”, although it should be understood that a stateless service may access and change a database or another local or shared data repository, thus influencing future processing operations of the same or other services. The application services in a service oriented architecture tend to be loosely coupled and highly interoperable.
A service oriented architecture can generally be used for all kinds of data processing tasks, but a preferred field of application is the support of business processes. Especially in this field, the technology of service oriented architectures has made significant progress in recent years and has now reached a level of maturity that allows the support of large scale enterprise business applications.
A decisive factor in the success of any service oriented development effort is that the right granularity must be found for the service interfaces. If the service interfaces are too fine grained, then the overall system performance will suffer because too many service calls are required to complete a task, e.g., a business task. Furthermore, a large number of fine grained services will be needed, and it becomes difficult to manage them. On the other hand, if a service interface is too coarse grained, then too much data is exposed. The service interface will then need to be adjusted whenever any element of its data changes. This leads to an unstable interface.
The challenge therefore is to find service interfaces of a suitable granularity in order to meet the requirements of high stability, high performance and good support for the respective business applications. This challenge is further complicated by the fact that the “right” granularity not only depends on the particular business application, but also on the communication structure between the components of the service oriented architecture. Coarse-grained service interfaces are more appropriate for the communication between remote nodes (i.e., nodes in different address spaces), while a small granularity (“chatty communication”) is better suited for local nodes that have little communication overhead.
A common approach to solving the problem of providing suitable service interfaces is to build service interfaces of various different granularities as independent services. However, this approach requires a duplication of code and thus increases the effort and costs for programming and supporting a service application.
Another common approach is to offer only coarse grained services and let the service requester extract the required data. However, as mentioned above, this approach leads to performance degradation and produces an overwhelming amount of information that must be transferred to and processed by the service requester.
In some systems it is possible to call another service from within a given service implementation. This functionality may be used to implement ad hoc solutions in a non-systematic way. Because there is no supporting service framework, much overhead will usually be incurred, thus leading to inefficient services.
Another difficulty in designing service interfaces of a suitable granularity is to provide a systematic way of organizing service objects, i.e., service operation parameters.
Based on the foregoing, there is clearly a need for a mechanism that supports the developer and/or user in providing a service interface with a suitable degree of granularity. There is also a need for providing a systematic way for aggregating service objects, service interfaces and/or service implementations. There is further a need for a technique that allows efficient execution of aggregated service implementations.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.